Current amendment E5 Latest printed amendment E4 66 pages A4. E - 0 - 0 SECTION E. The 1906A Operating System - GEORGE CONTENTS 1 - Literature 2 - The George Operating System and Subsystems 3 - The Filestore 3.1 Categories of file 3.2 Usernames 3.3 Filenames 3.4 Referring to files 3.5 Generation Numbers 3.6 Language Codes 3.7 Traps 3.8 Qualifiers 3.9 Terminal files 3.9.1 Basic Peripheral files 3.9.2 Direct Access files 3.9.3 Magnetic Tape files 3.10 On-line and off-line files 3.11 Temporary files 4 - Using the system 4.1 Commands 4.1.1 Built in Commands 4.1.2 Macro Commands 4.2 Jobs 4.2.1 Starting an off-line job (JOB and RUNJOB) 4.2.2 Starting an on-line job (LOGIN) 4.2.3 Ending an off-line job (ENDJOB) 4.2.4 Ending an on-line job (LOGOUT) 4.2.5 Context 4.2.6 Creating a file (INPUT, COPY and RENAME) 4.2.7 Erasing files (ERASE) 4.2.8 Access to files (TRAPGO,TRAPSTOP,TRAPLIST) 4.2.9 Other useful commands (LISTFILE,LISTDIR, ASSOCIATE,RETRIEVE,WHATSTATE,ABANDON) 4.2.10 Running an on-line job 4.3 Running programs 4.3.1 Running programs under George 4.3.2 Running programs under FAAST 4.3.3 Running programs under Eldon 3 4.4 Checking the progress of a job 4.4.1 The IF (IF) Command 4.5 Understanding and making use of the monitor file after a job run 5 - File amendment 5.1 The CORRECT macro 5.2 The EDIT (ED) command 5.3 The pointer 5.4 Off-line and on-line editing 5.4.1 Off-line editing 5.4.2 On-line editing University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 1 - 0 5.5 Editing instructions 5.5.1 Character string 5.5.2 Endpoint 5.5.3 Transcription and deletion of records and characters 5.5.4 Inserting text 5.5.5 Repetition 5.5.6 Merging files 5.5.7 The S instruction 5.5.8 Other facilities 5.5.9 Terminating or abandoning the edit 5.6 Special features for editing on-line 5.6.1 The Window facility 5.6.2 The Listing facility 5.6.3 The F (Forget) instruction 5.6.4 Break-in during an edit 5.7 Editor messages 6 - Subsystems 6.1 Fortran, Algol and Algol68 Short Turnround system (FAAST) 6.1.1 Jobs and commands 6.1.2 Limits on program runs 6.1.3 Library facilities 6.1.4 Submitting jobs to FAAST from an on-line console. 6.2 The Eldon3 terminal system 6.2.1 Running programs 6.2.2 File manipulation 6.2.3 Merging files 6.2.4 LISTDIR command APPENDIX 1 Username prefixes - departmental codes APPENDIX 2 Macros available PROG CORRECT NEWS PICTURE CHANGE LISTLDSA LISTMT FILELIST SOAP NULLIB & NULLIST University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 2 - 0 1. Literature The following ICL publications are specifically concerned with George: 4265: Introduction to George 4345: Operating Systems George 3 and 4. 4401: Writing George 3 and 4 job description. Manual 4265 provides a concise easy to read introduction to the George operating system, whilst manual 4345 is the authoritative reference manual and is somewhat indigestible. Nevertheless, the latter should be used for settling any point of doubt. Manual 4401 provides full details of how job descriptions are written. Normally users will only need to refer to this when they require facilities beyond those described in this Section, e.g. writing of macros. There is also a useful card, Form 14/113, entitled "A guide for MOP users". (MOP is the abbreviation for Multiple Online Programming, the interactive facilities of George). 2. The George Operating System and Subsystems The George operating system is a permanently active program that controls the flow of work through the larger 1900 series computers such as the 1906A. George takes over many of the organisational tasks previously performed by human operators. In particular once a job is input to the system it is controlled by George in response to commands supplied by the user without any operator action being required. The George Operating System described in this Section is either George 3 or George 4. Both these systems offer similar facilities and a job prepared on one system can usually be run on the other. The George 4 system used at Leeds offers virtual memory facilities and is appropriate for the paged hardware installed (see Section B). The George operating system provides for both off-line and on-line access, each mode of access offering a complete range of user facilities embracing program running and file manipulation. On-line access is provided via MOP (Multiple Online Programming) consoles, for which teletypes are provided in the central job reception area and in many University departments. Alternatively, access may be off-line via the card reader or paper tape reader in job reception (for BACKGROUND jobs) or from a remote job entry (RJE) station. RJE stations are provided within the University in the Houldsworth School and in the Textiles department for use by the departments in the 'West End' of the University campus. University of Leeds 8/11/78 Amendment E5 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 3 - 0 Jobs are not run in the order in which they are input to the system but are stored in a jobwell until the high level scheduler (strictly not part of George but a program that is always active when George is in the machine) decides to run them. The high level scheduler (HLS) decides which job to run next on the basis of scheduling data supplied by the user and machine resources available. Should a system break occur then any jobs waiting in the jobwell will be automatically preserved and any jobs running at the time of such a break will be rerun automatically when the system is re-instated. The backing store of the machine is also controlled by George. A user may store information in files in the 'filestore' by use of suitable George commands. The user refers to these files by a name that he chooses and does not need to know anything about particular backing store devices. George provides facilities for controlling and accounting resources such as mill time. Computing shares are allocated to users by their parent department, and an account is periodically produced showing for each user the resources he has used. The overheads on running work through George directly are substantial and can be avoided for much of the more straightforward program development work. Two "subsystems" which run under George are provided to process jobs without these overheads: FAAST (Fortran, Algol60 and Algol68 Short Turnround system) provides facilities for program development work. As its name suggests, FAAST aims to give a quicker turnround of jobs than is available through George direct. Jobs may be submitted to FAAST at an RJE station either on cards or paper tape. In addition a job to be run under FAAST may be initiated from an on-line console. The Eldon 3 terminal system provides on-line facilities for maintenance and program testing. Both George and these two subsystems involve two basic concepts for the user: a) A Job Command Language b) The Filestore. Because most commands involve the use of files the filestore will be considered first. University of Leeds 9/11/78 Amendment E5 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 4 - 0 3. The Filestore 3.1 Categories of file Users may store information in named files in the George filestore. There are two categories of files - terminal files and directory files. Terminal files are set up and maintained by the user for his own requirements, such as text or binary storage. Each user has associated with him a single directory file, which George maintains as a record of his terminal files. 3.2 Usernames All users of George must be accredited, and possess a 'username', which may be obtained on application to the Computing Service (See Section A). All usernames have the format :NAME, the colon being obligatory. For example :PHYSUSER :MECHSMITH could be valid usernames. The username allocated by the Computing Service will, in general, commence with a departmental identification code. Details of the codes allocated to different departments are listed in Appendix 1. 3.3 Filenames Users are primarily interested in the names of their terminal files. Such a name may consist of up to twelve characters the first of which must be alphabetic, e.g. DATAFILE2. A user may inspect his directory file, but does not need to know the name of the file. 3.4 Referring to files File names need only be unique to a particular user. If a user has started a 'job', he may refer to his own file by the filename as above, e.g. DATAFILE. However, to refer to another user's file he must specify the second user in the filename. This is done by prefixing the filename with the appropriate username and a dot separator, thus :JOHN.RESULTS. Note that files :DICK.RESULTS and :JOHN.RESULTS are different, yet each of :DICK and :JOHN could refer to their own file, within a job, as RESULTS. RESULTS is referred to as a local filename, whereas :JOHN.RESULTS is an absolute filename. In George terminology these filenames are termed "entrant descriptions". For a full explanation of these the user is referred to manual 4345. University of Leeds 4/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 5 - 0 3.5 Generation Numbers A filename has a generation number associated with it. Files are created with a generation number of 1, unless the user specifically requests otherwise. Any editing operation on a file produces a new file with the same name but generation number incremented by one. Thus it is possible to have several files with the same name but different generation numbers. This practice is not recommended but if files differing only in generation number do exist then the generation number must be specified to access the required version. If the generation number is omitted then the file with the highest generation number is assumed always. The generation number is written in parentheses following the filename, e.g. RESULTS(6) If the generation number is preceded by a sign (+ or -) then the generation obtained is relative to the latest version. Thus RESULTS(-0) or (+0) gives the highest generation number while RESULTS(-1) specifies a generation number 1 less than this. Thus if the latest version of a file was RESULTS(9) then RESULTS(-1) = RESULTS(8) Note that RESULTS(+1) refers to a generation number 1 higher than the latest. Clearly RESULTS(+1) does not refer to an existing file but can be used to create a new file. 3.6 Language Codes Files with the same file name may also be distinguished by a language code. This consists of up to four characters preceded by a solidus, and may be specified in parentheses as e.g. RESULTS(/ABCD), or, with a generation number as RESULTS(3/ABCD). University of Leeds 4/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 6 - 0 3.7 Traps George operates a system of file access traps, which define the ways in which a file may be accessed by a particular user. The five possible modes of access are: i) EXECUTE The contents of the file may be loaded into core and run. ii) READ The file contents may be read. iii) APPEND Information may be written to the end of the file. iv) WRITE The contents of the file may be overwritten. v) ERASE The file may be erased. For example, compilers are held in files belonging to a special user :LIB. All users have execute access to these files, but very few users are allowed write access. When a file is created the owner of the file has all these traps open to him unless a TRAPSTOP (TS) qualifier is used after the filename (see section 4.2.6). 3.8 Qualifiers Sometimes, certain details need to be supplied in addition to the filename. These take the form of qualifiers which are specified in parentheses after the filename, e.g. RESULTS(APPEND) APPEND is a qualifier that says that information should be added to the end of the file. Generation numbers and language codes may also be incorporated, e.g. RESULTS(3/DATA)(APPEND). Details of the various qualifiers and their use will be given in subsequent sections where relevant. 3.9 Terminal files These are files for the owner's use as opposed to directory files. Terminal files may be used to simulate a peripheral device (e.g. George allows a program to read data from the filestore when the program thinks it is reading cards). University of Leeds 4/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 7 - 0 There are 3 basic types of file corresponding to the 3 basic peripheral types: i) Basic (slow) peripheral files. ii) Direct access files iii) Magnetic tape files. 3.9.1 Basic Peripheral files These may be used to simulate slow peripherals such as card readers, line printers etc.. They may be subdivided into 3 types. These are: GRAPHIC NORMAL ALLCHAR A GRAPHIC file contains only those characters belonging to the ICL 64 character set. All basic peripheral files will be of mode GRAPHIC unless the user specifies otherwise. This means, however, that if a file is created from paper tape then the user must restrict his use of characters to the 64 character set, otherwise information will be lost. If it is required to use the full paper tape code (e.g. lower case letters) then the user must specify that his files are to be either NORMAL (i.e. they contain all the characters in the full set except runout and delete) or ALLCHAR (i.e. they contain all characters). Users are strongly recommended to use GRAPHIC mode wherever possible, but NORMAL mode may be necessary for some tasks. ALLCHAR should rarely be necessary. A typical use of basic peripheral files is where the output results from a program are preserved for use as input data for a subsequent program. 3.9.2 Direct Access files These may be subdivided into two types, DA (or disc) files and DR (or drum) files. They are used where large amounts of information need to be accessed in a random way, e.g. compiler workspace. (See Section L). 3.9.3 Magnetic Tape files These may be used like real magnetic tapes. They are a convenient method of storing moderate amounts of data that are to be accessed in a serial manner. Where large amounts of data are to be stored a real magnetic tape may be preferable. (See Section L). University of Leeds 4/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 8 - 0 3.10 On-line and off-line files A file that is immediately accessible is said to be on-line. At regular intervals the George system dumps to magnetic tape those files which have changed since the previous dump. These magnetic tapes provide a back-up system from which a file can be retrieved should the on-line copy be lost. An on-line file can disappear for two reasons: a) A system malfunction, (hopefully rarely) b) A backing store jam (only if there exists a copy on magnetic tape). The first reason is self explanatory. The second occurs when George no longer has sufficient space on revolving backing store to create new files. In this case files which have not been accessed recently and which are already preserved on magnetic tape are removed from the on-line filestore. A file which only exists on magnetic tape is said to be off-line. A file which is off-line cannot be accessed immediately. Any attempt to access the file will cause the file to be retrieved (i.e. copied from magnetic tape back into the on-line filestore). This retrieval process can be explicitly requested by means of the RETRIEVE command (section 4.2.9.4). It should be noted that Directory files are never put off-line and are written to magnetic tape in every dump. It is thus highly desirable to keep the size of Directories as small as possible and users are particularly encouraged to make regular use of the ERASE command (section 4.2.7) to remove deadwood. 3.11 Temporary files Any file with a filename commencing S-X is a temporary file and will automatically be erased from the system after a period of about 2 weeks. Temporary files are very useful for storing information which has a limited usefulness since the user does not have to remember to ERASE such a file. For example, the output from a program run may be stored in a file to enable extra listings to be obtained if the run is successful - such a file is probably not required a few days after the program run. A temporary file can be made permanent by renaming it with a name that does not commence with S-X (section 4.2.6.3). University of Leeds 9/11/78 Amendment E5 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 9 - 0 4. Using the system 4.1 Commands A user communicates with George, FAAST or Eldon3, by means of commands expressed in a Job Command Language (JCL). A command consists of a key-word (or verb) followed by at least one space and a series of parameters separated by commas, e.g. LISTFILE DATAFILE,*LP This LISTFILE command would list the basic peripheral file DATAFILE on the line printer. The order of parameters is usually important; in the case of LISTFILE the filename must be the first parameter. Many parameters are optional; some have to be expressly quoted "null" when it is necessary to preserve the position of a parameter but a preceding parameter is not required. Commands are limited to one per line but if a command is too long for a single line it may be spread over several lines by ending all lines except the last with a hyphen. Thus the The LISTFILE command above could be written as: LIST- FILE DATA- FILE,*LP Commands can be optionally labelled by preceding the verb with a sequence commencing 1Z... followed by a single space, e.g. 1ZNEXT LISTFILE DATAFILE,*LP George commands may be either built in commands or macro commands. 4.1.1 Built in Commands For brevity and convenience all commands built into George have a two letter abbreviated form, e.g. LF DATAFILE,*LP equivalent to the LISTFILE command in section 4.1. The most useful built in commands are documented in the following paragraphs. When each command is introduced in this Section its availability is indicated by code letters: B Background & RJE F FAAST M MOP E Eldon3. University of Leeds 17/12/74 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 10 - 0 4.1.2 Macro Commands Most of the George built in commands are very basic and a great many such commands may be required for an apparently simple job. For example, to compile and run an Algol program supplied on cards could require at least 20 to 30 commands and this would provide no protection against errors. A more suitable set of instructions might require >100 commands. To avoid a user having to prepare and repeat long and tedious sequences of JCL, George allows commands to be stored in a file. The filename may then be written as a verb and all the commands stored within the named file will be obeyed. A command file used in this way is called a macro command. Macro commands may be written by users for their own use or may be provided by the Computing Service for general use. When George encounters a verb which is not a built in command it first searches the user's directory for a file with the name of the command. If this search is unsuccessful George then searches a special directory (:MACROS) to try and find the file. Macros provided by the Computing Service are all stored in the directory :MACROS and users must clearly ensure that they do not have files in their directory with the same name as these macros if they wish to use them. It is possible to supply parameters to a macro command, parameters which can be accessed from within the macro. Any description of how to write macros is beyond the scope of this Section and manuals 4345 and 4401 should be consulted by such interested users. A macro may within itself call other macros. As an example of the usefulness of macros, to compile and run an Algol program supplied on cards using the PROG macro provided by the Computing Service, the single command required would be: PROG ALGOL (followed by the program card deck). This command incorporates all necessary error checking. A full description of the most useful macros provided by the Computing Service is given in Appendix 2. Most users should look to these macros for running programs and servicing their work, as not only are they versatile and well tested, but specialist assistance is readily available should it be required. Macro facilities are not available in FAAST or Eldon3, but the system macros PROG and CORRECT are provided as built in commands. University of Leeds 12/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 11 - 0 4.2 Jobs A job consists of an ordered set of commands. The first command in the set introduces the job and associates with it a jobname and a username. A job may be run either off-line or on-line. An off-line job may be submitted via either cards or paper tape (JOB and RUNJOB commands) or from an on-line terminal (RUNJOB command); once the user has submitted such a job to the computer he has no further control over it. For an on-line job commands are typed at a console and each command is obeyed and a suitable response obtained before the next command is input. The user therefore has much greater control over an on-line job since he can interact directly with the system. File editing in particular is much less error prone when performed on-line. On the other hand, production running is often better handled off-line. Off-line jobs should be organised so that they can be re-run without a) corruption of files (e.g. repeat of an EDIT), and b) avoidable waste of c.p.u. time, since jobs caught in a system break will be rerun. When any job starts to run, a temporary file, called the monitor file, is created for the job; messages concerning the progress of the job are sent to this file. At the conclusion of the job this file will normally be listed on the lineprinter and then erased; alternatively the monitor file may be retained by the RETAIN option of the ENDJOB command or the RT parameter of the PROG macro. 4.2.1 Starting an off-line job (JOB and RUNJOB) An off-line job is initiated by either a JOB command or a RUNJOB command, depending on whether a stored job description is to be used. The purpose of the JOB or RUNJOB command is to associate a jobname and a username with the job and to specify scheduling information. The scheduling information is specified by means of the jobdata JD parameter. This parameter takes the form: JD(JT time,MZ size,MQ quota,UR urgency,MT tapes) e.g. JD(JT 30,MZ 300K,UR D) Any of the items in parentheses may be omitted (in which case a default value is assumed) and spaces are optional. Note that when running a job for the first time intelligent guesses must be supplied for the scheduling parameters (a good guess is to use the default values). Once the job has been run more accurate values can be obtained from the job's monitor file. The items in parentheses are utilised as follows: a) JT time e.g. JT 120 SECS University of Leeds 6/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 12 - 0 JT 2 MINS JT 30 The JT (jobtime) parameter specifies the maximum c.p.u. time that a job will use. A job will automatically be abandoned if its jobtime is exceeded. The time may be specified as SECS or MINS; if neither is stated then SECS is assumed. If the JT parameter is omitted then a default jobtime of 30 SECS is assumed. A maximum jobtime of 30 MINS is normally permitted, although longer jobs may be run by individual arrangement with the Computer Manager. (Such jobs may be subject to an exceptionally long turnround.) b) MZ size e.g. MZ 30000 MZ 60K MZ 0 The MZ (maxsize) parameter specifies the maximum virtual core size that any program run by the job requires. No program run in this job will be able to expand to a size greater than this figure. The size may be specified either as a number of words or as a multiple of 1024 words (i.e. as nK). A job which does not require to create a core image (i.e. does not run a program) should specify a maxsize of 0. If the MZ parameter is omitted a default value of 128K is assumed. The size needed for a core image can be found from the SIZE GIVEN messages in the monitor file. c) MQ quota The MQ (maxquota) parameter specifies the maximum real core that the job requires. If this parameter is omitted a default MQ based upon the maxsize is assumed. While this parameter is not essential (a job will not fail without it) the scheduling system benefits if jobs requiring >20K quota use a MQ parameter. The quota used by a program can be found from the MAXQ figure in the DELETED message in the monitor file. Note that if too small a maxquota is specified then the job may perform an excessive number of page turns. Accordingly the PT figure in any DELETED message should also be examined. If this is several tens of thousands then the job has too small a maxquota. Any user requiring a maxquota of >60K should consult the Programming Advisory Service before proceeding. d) UR urgency e.g. UR D UR Z The UR (urgency) parameter specifies the priority to be given to the job for scheduling purposes. A user may specify an urgency in the range D to R inclusive and Z. Urgency D work is given highest priority, urgency Z lowest priority. Jobs submitted at urgency Z will only be run if there is no other work in the system. Jobs run at high urgency will be given higher priority but the charge for such jobs is higher. If the UR parameter is omitted then a default urgency is assumed. University of Leeds 9/11/78 Amendment E5 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 13 - 0 e) MT tapes e.g. MT 2 The MT (magtapes) parameter specifies the maximum number of real magnetic tapes to be used by the job. If the MT parameter is omitted then a default value of 0 is assumed. Note that it is important that these parameters should be correctly stated. Failure to do so may cause the job to be given an adverse turnround or even to fail if too short a jobtime or too small a maxsize is specified. 4.2.1.1 The JOB (JB) command B,F,M format: JOB jobname,username,JD(scheduling parameters) e.g. JOB FIRST,:ME,JD(JT 10) This command initiates a job called FIRST running under a user :ME, and the maximum jobtime is not to exceed 10 seconds. The jobname parameter should be a 12 character filename which is different from any file existing in the user's directory. In addition to initiating the job the JOB command creates a temporary file, the job description file which is destroyed when the job ends. When George reads a JOB command all the records that follow up to a record consisting of four asterisks in columns 1 to4 inclusive, viz **** are copied into the job description file. This file is then obeyed. In this way George avoids the need for a job to have a physical card reader or paper tape reader dedicated to it while it runs. The record consisting of **** at the end of the job is called the job terminator. An optional parameter following the username can be used to change the default record of **** to any other four characters, e.g. JOB SECOND,:HIM,T#### introduces a JOB terminated by a record consisting of ####. The **** terminator will normally only be changed for certain jobs which require a **** record to be supplied within the job description, perhaps as part of some data. University of Leeds 9/11/78 Amendment E5 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 14 - 0 4.2.1.2 The RUNJOB (RJ) command B,M,E format: RUNJOB jobname,username,jdfilename,JD scheduling list,- PARAM(a1,a2...) e.g. RUNJOB NEXT,:THEM,PROG,JD(JT 1MIN),PARAM(ALGOL- MYPROGRAM) This command, like the JOB command, initiates a job running under a specified user. In this case, however, no job description file is created, but the job description is read from the file specified in the jdfilename parameter. The RUNJOB command is particularly useful when it is required to run many similar jobs. Rather than introduce each job with a JOB command and create a temporary job description file for each run a job description file is created once by an INPUT command (see section 4.2.6) and each job is then initiated by a separate RUNJOB command. A job description file used in this way is analogous to a macro command as described earlier, and parameters may be supplied to this job description via the PARAM parameter of the RUNJOB command. Thus, the example given uses the PROG macro as its job description file and the single command is sufficient to compile an Algol program stored in the file MYPROGRAM and run it. Note that if the job description filename specified in the RUNJOB command does not exist in the user's directory then George will look for a file with the required name belonging to :MACROS. If a macro is used in this way by a RUNJOB command then any program or data must be in files. The RUNJOB command (as above) may be submitted off-line (via cards or paper tape) or from an on-line console which is not logged in. The RUNJOB command may also be used within a job to initiate another job running under the same user. In this case the username parameter is omitted. e.g. RUNJOB SECONDBIT,PROG,JD(UR D,JT 120),PARAM(BIN- SOLVBIN,DATA COEFFS) This use of RUNJOB is particularly useful for initiating a background job from a on-line console which is logged in. 4.2.2 Starting an on-line job (LOGIN) M,E The LOGIN (LN) command format: LOGIN jobname,:username e.g. LOGIN TUESDAY,:ME The LOGIN command initiates an on-line job. No job description file is required since commands are read from the on-line console as required. Any messages sent to the monitor file are also sent to the console so it is usually unnecessary to print out the monitor file. University of Leeds 5/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 15 - 0 4.2.3 Ending an off-line job (ENDJOB) The ENDJOB (EJ) command B,F format: ENDJOB action on monitoring file e.g. ENDJOB This command terminates a job. If the command alone is given then the whole of the monitoring file is listed on the line printer. That is, ENDJOB = ENDJOB ALL Alternatively, ENDJOB NONE ends a job without listing the monitoring file. Note that every job must obey an ENDJOB command. Many macros (e.g. PROG) therefore contain an ENDJOB command and it is here not normally necessary for the user to supply his own. Occasionally it may be desirable to preserve the monitoring file for later inspection. This can be achieved by an optional RETAIN (RT) parameter after the "action on monitoring file" parameter, e.g. ENDJOB NONE,RT(MONITOR) would end the job without listing the monitoring file but a copy of the monitoring information would be preserved in a file MONITOR. 4.2.4 Ending an on-line job (LOGOUT) The LOGOUT (LT) command M,E format: LOGOUT action on monitoring file e.g. LOGOUT NONE This command is analogous to ENDJOB and is used for ending an on-line job. However, the default action on the monitoring file is NONE, that is, LOGOUT = LOGOUT NONE The monitoring file may be retained if required (as for an off-line job). University of Leeds 13/12/74 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 16 - 0 4.2.5 Context When a job is initialised by a JOB, RUNJOB or LOGIN command a user name is associated with the job. In George terminology we say that the context has changed from NO USER to USER. When an ENDJOB or LOGOUT command is later obeyed the context reverts from USER to NO USER. There are several other contexts within the George system. The most important of these occurs then a program is loaded, when the context changes from NOT CORE IMAGE to CORE IMAGE. When a core image is later deleted the context reverts to NOT CORE IMAGE. If the "break-in" facility is used on-line (section 4.2.10) the context changes from NOT BREAK IN to BREAK IN. Commands typed in by the operator on the control console are said to be in OPERATOR context. Certain George commands may only be used in certain contexts and are forbidden in others. Some George commands have different formats depending on the context, e.g. RUNJOB. All the following commands should be obeyed in USER context unless stated otherwise. 4.2.6 Creating a file (INPUT, COPY and RENAME) 4.2.6.1 The INPUT (IN) command B,M,E format in NO USER context: INPUT username,filename,terminator e.g. INPUT :SHE,MYPROGRAM format in USER context: INPUT filename,terminator e.g. INPUT MYDATA The INPUT command creates a basic peripheral file with the name specified provided the file does not exist. If the file exists then it will be overwritten providing the user has WRITE access to the file. All records following the INPUT command up to and including a record commencing with four asterisks **** are copied into the file. An alternative terminator to the INPUT command may be specified by an optional terminator parameter which takes the form: S<any 4 characters> or T<any 4 characters> The S option specifies that the terminator is to be stored in the file; the T option specifies that the terminator is not to be stored. In the absence of a terminator parameter S**** is assumed. E.g. INPUT :YOU,FILE2,T#### If an alternative terminator is specified do remember to include it. When a file is being created from cards or paper tape then INPUT should be used in NO USER context (i.e. the INPUT command is not preceded by a JOB command). This is because when an INPUT is done in USER context (following a JOB command) it is necessary to copy all the file first into the temporary job description file and then into the file specified. This is inefficient and should be avoided. University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 17 - 0 INPUT in USER context is mainly used from an on-line console after a LOGIN command has been obeyed. Since the LOGIN command does not create a job description file the inefficiency described earlier does not arise. When a file is created by an INPUT command all traps are left open (i.e. the user has READ, WRITE, APPEND, ERASE and EXECUTE access available to him). A TRAPSTOP (TS) qualifier may be used in parentheses after the filename to remove any of these modes. The qualifier takes the form: TS(access mode,access mode,....) e.g. INPUT :THING,SECRET(TS(ERASE,WRITE)) would INPUT a file called SECRET and the ERASE and WRITE traps to the file would be closed. If a file is overwritten by the INPUT command the trap settings are left as they were for the original file unless a TRAPSTOP (TS) or TRAPGO (TG) qualifier is used to change the settings. The TRAPGO qualifier has the same format as the TRAPSTOP qualifier but gives rather than removes a mode of access. For example in the command INPUT :THING,SECRET2(TS(ERASE),TG(WRITE)) two qualifiers are used, one to remove ERASE permission and one to give WRITE permission to the file. Note also that the trap settings are changed after the INPUT has been done. It is not therefore possible to overwrite a file which has no WRITE trap by including a TG(WRITE) qualifier on the INPUT command. A separate TRAPGO command (section 4.2.8) must be obeyed before attempting the INPUT. The mode of a file created by INPUT is assumed to be GRAPHIC (i.e. restricted to the 64 character ICL card code). If input is from paper tape and it is required to use the 128 character code then a NORMAL qualifier must follow the file name, e.g. INPUT :ME,MYTAPE(NORMAL) Use of a NORMAL qualifier does not allow the use of runout and delete characters, so that in very rare cases it may be necessary to use an ALLCHAR qualifier rather than NORMAL. The INPUT command can also be used to append records to an existing file providing the user has APPEND access to the file and an APPEND qualifier follows the filename, e.g. INPUT :HIM,CUMDATA(APPEND) It is not possible to APPEND records of one type e.g. NORMAL to a file of another type e.g. GRAPHIC. If the file specified does not exist then the APPEND qualifier is ignored and the file created in the usual way. University of Leeds 30/1/74 Amendment E2 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 18 - 0 4.2.6.2 The COPY (CY) command B,M format: COPY filename1,filename2 e.g. COPY :FRED.PROGRAM,MYPROGRAM The COPY command makes a copy of filename1 in filename2. If filename2 does not exist it will be created and will be the same type as filename1. If filename2 exists it will be overwritten providing WRITE access is allowed. TRAPGO, TRAPSTOP and APPEND qualifiers may be used with filename2 as for the INPUT command. COPY is often used to make a copy of a file belonging to one user under another user. In this case the specification of filename1 must be an absolute filename (i.e. it must be of the form username.filename) and the owner of filename1 must have previously given READ access to the current user. 4.2.6.3 The RENAME (RN) command B,M format: RENAME filename,newfilename e.g. RENAME S-XTEMP,PERMANENT Strictly this command does not create a new file but changes the name of an existing file. Thus, the example shows a temporary file being renamed to make it permanent. 4.2.7 Erasing files (ERASE) B,F,M,E The ERASE (ER) command format: ERASE file1,file2,... e.g. ERASE MYFILE The files specified in the command are removed from the filestore providing the user has ERASE access. Up to 24 files may be deleted by a single ERASE command. University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 19 - 0 4.2.8 Access to files (TRAPGO, TRAPSTOP and TRAPLIST) Access to files is controlled by traps. The following modes of access are allowed READ, WRITE, APPEND, EXECUTE and ERASE. A file is initially created with all traps open to the owner of the file. The owner (only) can change these traps and grant other users access by means of TRAPGO and TRAPSTOP qualifiers to the filename when the file is written or by the use of separate TRAPGO and TRAPSTOP commands. The access mode ALL may be used to indicate all the above access modes. 4.2.8.1 The TRAPGO (TG) command B,M,E format: TRAPGO filename,username,access mode,access mode ... e.g. TRAPGO MYFILE,:HIM,READ,EXECUTE TRAPGO MYDATA,ALL 0a The user specified is granted access in the modes specified to filename. The username parameter may be omitted in which case the owner of the file is assumed. 4.2.8.2 The TRAPSTOP (TS) command B,M format: TRAPSTOP filename,username,access mode,access mode ... e.g. TRAPSTOP MYDATA,ERASE This command is analogous to TRAPGO but removes access. 4.2.8.3 The TRAPLIST (TL) command B,M format: TRAPLIST filename1,output filename e.g. TRAPLIST MYPROGRAM Enables a user to check the access modes allowed both to himself and other users. Output from the command consists of a single line for each user permitted access to the file in the form: :USER,access modes The second parameter is optional, if omitted the output is sent to the monitor file/on-line console, if present the output goes to the file specified. University of Leeds 6/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 20 - 0 4.2.9 Other useful commands The LISTFILE (LF) command B,F,M,E format: LISTFILE filename,peripheral,FROM startpoint,LINES number or TO endpoint,NUMBER,PROPERTY prop e.g. LISTFILE DATA,*LP This command enables a listing of a basic peripheral file to be obtained. The first parameter, the filename, must always be present. The other parameters are optional and may be in any order. They have the following meanings: peripheral either *LP or *TP causes the listing to go to either a line printer or tape punch. If omitted the listing is to the monitor file (and therefore to the console for an on-line job). FROM number causes the listing to start at the record FROM /string/ specified (as for editing, section 5.5.2, FROM S/string/ except that number here specifies an absolute record number). By default the file is listed from the beginning. TO /string/ causes listing to continue until the first TO S/string/ occurrence of the specified record. By default the listing continues to the end of the file. LINES number causes the number of lines specified to be listed. By default the listing continues to the end of the file. NUMBER causes the listing to be preceded by line numbers. This facility can be useful prior to editing a file containing, for example, many similar records. PROPERTY prop enables the user to specify that the listing is to go to a peripheral with a particular PROPERTY. (E.g. a job submitted via a RJE station will normally route listfiles to the RJE station printer or punch. The parameter PROPERTY CENTRAL would cause this listing to appear instead on the faster peripherals in the machine room). The parameter identifiers FROM, LINES, NUMBER and PROPERTY can be shortened to FR, LI, NU and PR respectively. Users are recommended to make sensible use of the FROM and LINES (or TO) parameters so that only those parts of a large file that are really required are actually listed. University of Leeds 6/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 21 - 0 4.2.9.2 The LISTDIR (LD) command B,F,M,E format: LISTDIR username,listing level,destination, PROPERTY prop e.g. LISTDIR LISTDIR ,,*LP This command causes a summary of the files owned by the user specified to be output. All parameters are optional but the specified order must be adhered to. The parameters are interpreted as follows: username specifies the user for whom the summary is required. This parameter is usually omitted in which case the user under whose job the command is obeyed will be assumed. listing level is either HIGH or LOW and controls the amount of information output. If neither is specified LOW is assumed. destination either a peripheral type (*LP or *TP) specifying the peripheral on which the summary is to appear, or a filename specifying a file to which the summary is to be written. If omitted the summary is sent to the monitor file. PROPERTY used with either *LP or *TP specifies a peripheral with a particular property as in the LISTFILE command. Note that the examples given are the commonest forms of the LISTDIR command. Note also the use of commas and null parameters to preserve the parameter order. 4.2.9.3 The ASSOCIATE (AE) command B,M format: ASSOCIATE PR property,LF optional peripheral type e.g. ASSOCIATE PR NOLINES,LF Sometimes a user wishes to send all listings produced by a particular job to a specific lineprinter, for example the CENTRAL printers are loaded one with lined paper - PROPERTY LINES, and one with unlined paper - PROPERTY NOLINES. A user can attach a PROPERTY parameter to each LISTFILE or LISTDIR command, but this can get tedious. Following an ASSOCIATE command all listings (including the monitor file if output) go to a device with the property specified in the ASSOCIATE command unless a specific property is specified by the listing command. The peripheral type (*LP or *TP) following the LF is optional; if present only listings to the device specified are affected, if absent all devices are included. If several ASSOCIATE commands occur in one job the last one obeyed is the only one to be effective. University of Leeds 6/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 21 - 1 4.2.9.4 The RETRIEVE (RV) command B,M format: RETRIEVE file1,file 2, ....... e.g. RETRIEVE ROOTPROG,ROOTDAT This command causes the files specified to be brought on-line if they are off-line, and produces a confirmatory message if they are already on-line. Any attempt to access a file which is off-line via a George command will cause the file to be retrieved automatically and the job will be held up until this is done. An attempt to access a file which is off-line via Eldon3 will cause the file to be retrieved but the job will continue to the next command. If, say, a macro file is off-line and the macro accesses other files which are off-line then the job can be held up several times retrieving these. A RETRIEVE command at the start of the job enables all the files to be retrieved at once and the job need not be held up again. The RETRIEVE command is particularly useful for on-line jobs. After logging in, the user can issue a list of retrieves and can then Break-in (section 4.2.10) and do something else. Later the user can access the files which were retrieved and need not have to wait. 4.2.9.5 The WHATSTATE (WS) command B,M format: WHATSTATE job selection parameter e.g. WHATSTATE JOB MYRUN1 When an off-line job is input to George it goes into the jobwell, whence depending on the scheduling requirements of the job and the machine loading it may be several hours before the job is run. The WHATSTATE command enables a user to check on the progress of a particular job or jobs. Full details of this command are given in the manual 4345, but the most commonly used job selection parameters are: JOB jobname to enquire about a particular job. ALL to enquire about all jobs submitted by this user. The following information is output in response to this command for each job requested: JOB-NO a unique number by which this job is known to the system. MOP For a MOP job, Idd where dd is the identifier of the console. For an off-line job, N unless the job was submitted via a RJE station in which case Rdd where dd is the identifier of the RJE station. USERNAME Username of the user. JOBNAME Jobname of this job. UR Urgency of this job. University of Leeds 6/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 21 - 2 CP Either the characters WL indicating that the job is in the jobwell, or a number which is an internal scheduling parameter. JOB-TIME For a job in the jobwell these are the PRO-TIME arrival date and time. For a job which is running these are the jobtime used so far and the time remaining for the current core image. QUOT For a running job, the program's current quota. If a job is "running" but held up for some reason (e.g. retrieval of a file) then the above information is followed by a WAITING message explaining this reason. 4.2.9.6 The ABANDON (AB) command B,M format: ABANDON jobname e.g. ABANDON DUDJOB Sometimes after a job has been submitted to the system it is desired to prevent it running, for example the job may run a program which has been found to be in error. The ABANDON command enables a user to abort jobs submitted by him. University of Leeds 6/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 22 - 0 4.2.10 Running an on-line job As described earlier an on-line job is initiated by a LOGIN command. Before this command can be typed it may be necessary to input a "Control A" character (i.e. the "control" key is held down and A pressed) in order to wake up the system. The system will respond with an introductory message and the "invitation to type" sequence. This takes the form: time_ where time is of the form hh.mm.ss. A command may now be typed followed by an "Accept" symbol. It is very easy to type when the system is not listening, so care must be taken to ensure that the invitation to type has been received. If no message is typed in response to the invitation then the system will eventually "time out" and produce a message TIMED OUT or CLOSED DOWN depending on whether the terminal was logged in or not. Control A must be pressed to wake the terminal up again. If an error is made in typing a command then the _ symbol may be used and has the effect of deleting the previous character. __ would delete the previous two characters and so on. e.g. LOGOM__IN is equivalent to LOGIN If a message is badly in error then if "Control X" is typed the message CANCEL_ is output and a fresh attempt can be made. Each command is obeyed as soon as the Accept key is pressed. If the command is in error a suitable message is output and the user can try again. When it is necessary to type a sequence extending beyond one line the Accept key must be pressed after each line. 'Newline' and 'Carriage Return' characters are never used. Sometimes a command may be issued and it is required to halt its execution (e.g. a PROG command is used to initiate a program run and an error is discovered in the program in the meantime by the user). This can be achieved by using the Break-In facility. If the symbol Control A is pressed then the current action of the system is halted and control returned to the console. The exact effect of the Break-in depends upon the command being obeyed: a) Within an EDIT (see section 5.6) the current editing instruction is terminated and control returns to the console for the next editing instruction. The console is not left in BREAK IN Context. University of Leeds 4/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 23 - 0 b) Within a LISTFILE (or LISTDIR) command a message of the following form is output: BREAK IN BROKEN IN AND ABANDONED IN LISTFILE time_ Note that in this case it may be necessary to press Control A twice to suppress the console output. c) Within other commands the message output is BREAK IN BROKEN IN position time_ where position gives the command where the break-in occurred. After cases b) and c) the console is left in BREAK IN context. A variety of commands can then be input following the invitation to type, e.g. an EDIT might be performed to correct a program text in error. The Break-in is terminated by the single command QUIT (QU) In the case c) only the Break-in may be terminated and the original instruction resumed by the command CONTINUE (CU) Note that if a job with a core image is broken-in on and QUIT is used, then the core image is deleted, if CONTINUE is used execution continues. When running a job on-line, the verbosity of George error messages can be tedious to an experienced user. To overcome this the following commands are provided: 4.2.10.1 The QUIET (QI) command M format: QUIET This command suppresses the full printing of error messages. Any error will generate the message: ERROR The suppression may be terminated by typing the command: CANCEL QUIET (CC QI) 4.2.10.2 The PRINTLAST (PL) command M format: PRINTLAST This command can be used in conjunction with the QUIET command. If following the use of QUIET the message ERROR is received then if desired the full text of the error message can be printed by typing the PRINTLAST command. University of Leeds 6/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 24 - 0 4.3 Running programs 4.3.1 Running programs under George A large number of commands are required to run a typical program; programs are therefore almost always compiled and run using a suitable macro, such as the PROG macro which is fully documented in Appendix 2. One of the most important features of George is that a program does not require real peripheral devices to be available to it when it runs; peripherals can be simulated by files in the filestore. Typically, the 1906A runs several programs concurrently and nearly all these programs will require to output to a line printer; it would be uneconomic to have many line printers dedicated to these programs since they would stand idle much of the time. A better solution is to accumulate output from a program in a file and then list this file on a line printer when the program has finished. In this way each job drives a real line printer flat out for a short period of time only and two line printers are capable of printing the output from a large number of jobs. This "off-lining" of peripherals may be controlled by parameters to PROG. The following options are available to a user: For input peripherals: a) Simulate the peripheral by reading from the job description file. Since the job description file is often created by a JOB command this means that the peripheral input is supplied as part of the deck of cards or paper tape that comprises the job. It is quite common for a program to be reading "paper tape" but the data in the job description to have come from cards. b) Simulate the peripheral by reading from a named filestore file. c) Use a real live peripheral. This should only be necessary when reading magnetic tape or unusual (non-standard) codes on cards or paper tape. For output peripherals: a) Simulate the peripheral by outputting to a temporary file which is later listed. Most simple jobs produce output in this way and the user may well not be aware that his job did not have its own line printer. b) Simulate the peripheral by outputting to a named file which may be listed. An output file produced in this way may be used as input to another program providing that the input and output modes are compatible, that is, magnetic tape output is only used for magnetic tape input, direct access output is only used for direct access input and basic peripheral output is only used for basic peripheral input. In the latter case, for example, output to a line printer file can be read via a card reader by another program. University of Leeds 6/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 25 - 0 No problems occur if basic peripheral files are limited to GRAPHIC mode. If, however, a NORMAL or ALLCHAR file is created by output to a tape punch then some characters may be lost if an attempt is made to read it as cards. c) Use a real live peripheral. This should only be necessary when using magnetic tape. Details of how these options are provided and utilised are given in the definitive description of the PROG macro in Appendix 2. 4.3.2 Running programs under FAAST Most Fortran, Algol60, Algol68 and Snobol programs can be run under FAAST. For Algol 60 and Fortran a different compiler, an in-core compiler, will be utilised. For full details, and the few minor limitations, see section 6.1 and the relevant language Sections (G, F, Q or P respectively). 4.3.3 Running programs under Eldon3 There are three ways of running programs under Eldon3: 4.3.3.1 The RUN command E This command provides compilation and execution of Algol 60, FORTRAN, or Algol 68 programs, and returns output to the terminal. Where desired, both the program text and the relevant data can be included in the same file. Full details are given in section 6.2. 4.3.3.2 The FAASTPROG command B,F,M,E This operates via FAAST (see section 4.3.2) and is identical in use and operation. 4.3.3.3 The RUNJOB command B,M,E This operates in the standard manner although only in USER context. 4.4 Checking the progress of a job If the system breaks for any reason, jobs running at the time of the break are automatically rerun. Certain steps within a job may not be repeatable (either because they fail or, worse, cause corruption) so it is important to be able to detect rerunning. Also many jobs contain several logical steps (e.g. an edit followed by a program run). It is often pointless (and wasteful) carrying on with the later stages of such a job if one of the earlier stages fails. The IF command may be useful in these cases: 4.4.1 The IF (IF) command B,M format 1: IF condition,command format 2: IF condition,(command1) ELSE (command2) University of Leeds 12/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 26 - 0 The IF command enables a job to obey different commands depending on some condition being satisfied or not. A full description of the condition parameter is beyond the scope of this Section but three forms of the IF command are particularly useful: a) The RESTARTED condition enables a job to check if it is being rerun. Consider the following example: JOB RUNAGAIN,:POORUSER IF RESTARTED,ENDJOB PROG BIN UPDATE,*MT1=(20166),*MT2(WRITE)=(20419) **** The IF command aborts the job if it is re-run, so avoiding possible magnetic tape corruption. b) Several programs may be run in a job by successive calls of PROG, providing an EXIT parameter is used to prevent PROG obeying an ENDJOB command. However, it may well be that it is only required to run program 2 if program 1 works successfully. The PROG macro displays or outputs a message starting ERROR... if anything goes wrong. The following example shows how this might be used in a two program job: JOB RUN,:ME PROG BIN FIRST,FILE*LP0=NEWDATA,EXIT IF DISPLAY(ERROR),ENDJOB PROG BIN SECOND,DATA NEWDATA **** The IF command ensures that the second program, which requires data generated by the first program, is only run if the first program ends successfully. c) It may be useful to check for the existence or otherwise of a particular file. Consider the following job: JOB EDRUN,:YOU IF NOT EXISTS(MYDATA(15)),GO 1ZL CORRECT MYDATA T#16,P100,E 1ZL PROG BIN REGRESS,DATA MYDATA **** The IF command checks if a particular generation of the file MYDATA already exists. If the file does not exist then the command GO 1ZL transfers control to the command labelled 1ZL, i.e. the PROG statement. Thus, the IF command prevents the CORRECT being performed on the wrong version of a file with likely disastrous results. Another use of this condition, which produces a similar effect to example (b), is: JOB RUN1,:ME PROG BIN FIRST,FILE*LP0=NEWDATA,EXIT IF NOT EXISTS(NEWDATA),ENDJOB PROG BIN SECOND,DATA NEWDATA **** University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 27 - 0 4.5 Understanding and making use of the monitor file after a job run By its nature the monitor file is a most useful, often essential, piece of information when tracing the actions actually performed by a job and/or identifying many causes of failure. In a trivial sense every monitor file is unique, but much can be accomplished by a simple illustration. Consider the following job (printed on a reduced scale so that it can be all accomodated on two facing pages): o-----------------------o ! Affix photo-reduction ! ! of a specimen ! ! monitor file ! o-----------------------o University of Leeds 4/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 28 - 0 o------------------------o ! Affix photo-reduction ! ! of an explanation of a ! ! specimen monitor file ! o------------------------o University of Leeds 4/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 29 - 0 5. File Amendment Any basic peripheral file may be amended by use of the George editor. Editing a GRAPHIC mode file is straightforward but problems may arise if an attempt is made to edit a file in NORMAL or ALLCHAR modes. Users with this need can use the S instruction provided by the enhanced editor incorporated in the FAAST subsystem or Eldon3 terminal system. The editing process copies the file to be edited (the old file) into a new file making changes as directed by editing instructions. The editing instructions are normally read from the job source (i.e. job description file or on-line console). 5.1 The CORRECT macro B,F,M,E The most usual way of entering the George editor is by means of the macro command CORRECT filename Here the oldfile is edited into a newfile which has the same name but has a generation number one greater. If the edit is successful then the oldfile is erased. If the edit fails off-line or the Q (Quit) option is used on-line then the new file is erased and the old file is preserved unchanged. 5.2 The EDIT (ED) command B,F,M,E This command offers some additional facilities to the CORRECT macro but for normal use has the disadvantage that both the old and new files are retained when the edit is ended regardless of whether the edit was successful or not. The general form of the command is: EDIT oldfile,newfile,editfile where, oldfile - is the file to be amended and this parameter is obligatory. newfile - is optional and is the name of the new file to be created. If this parameter is omitted then the newfile produced has the same name as oldfile and a generation number one greater. editfile - is also optional and causes the editor to read editing instructions from the file specified. If this parameter is omitted, (as is usual), then editing instructions are read from the job source (i.e. job description file or on-line console). Thus, ED MYFILE(1) would produce a new file MYFILE(2) from MYFILE(1) using editing instructions from the job source. University of Leeds 13/12/74 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 30 - 0 Similarly, EDIT MYFILE,YOURFILE would produce a new file YOURFILE from MYFILE using editing instructions from the job source. 5.3 The Pointer A serial file is regarded as a series of records, which, for all practical purposes, correspond to a unit on some physical medium, i.e. a card, a block of paper tape, or a line of print. Each record consists of a series of characters. Editing is done in terms of a conceptual pointer which indexes a particular character within a particular record of the old file. The pointer is initially at the first character of the file, that is, character 0 of record 0. Editing instructions are used to move the conceptual pointer from the beginning to the end of the old file creating the new file by transcribing text from the old file and by deleting, inserting and replacing characters and records as specified by the editing instructions. 5.4 Off-line and on-line editing Any editing operation may be performed either off-line or from an on-line console. Editing is ideally suited to on-line access since progress is visible and errors can be corrected immediately, e.g. by F(forget) command. Some editor facilities can only really useful on-line, e.g. W(window). 5.4.1 Off-line editing The editor is entered by either the CORRECT macro or EDIT commands issued from within the job description. The editing instructions follow immediately on the next lines or cards of the job description. Each instruction is terminated by a comma or newline. 5.4.2 On-line editing The editor is entered by typing either the CORRECT or EDIT commands on an on-line console after logging-in. The system replies EDITOR IS READY 0.0_ 0.0 is the initial position of the pointer (record 0 character 0). A line of editing instructions may now be typed followed by pressing the Accept key. When the editor is ready to accept more editing instructions the system outputs m.n_ where m.n is the new position of the pointer (record m character n). University of Leeds 9/1/75 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 31 - 0 5.5 Editing instructions Instructions to the editor are all one character mnemonics usually followed by associated parameters. Each record of input to the editor may contain several editing instructions separated by commas. All editing instructions except the I instruction (section 5.5.4.1) must be complete in one record. Records input to the editor are listed to the monitoring file in the COMMANDS category. Several editing instructions require as a parameter a character string and several an endpoint. It is convenient to describe these before the various editing instructions. Editing facilities are available on all systems (B,F,M,E) unless otherwise stated. For enhanced facilities for NORMAL files see section 5.5.7. 5.5.1 Character string A character string consists of any number of characters enclosed within a pair of identical string delimiters. These are taken from the character set: : ; < = > ? ! " $ % & + / The chosen string delimiter may not occur within the character string which is why a choice of delimiters is available. Thus to specify x:= x+2 as a character string /x:= x+2/ would be suitable where / is the string delimiter. But to specify x:= x/2 it would not be correct to use /x:= x/2/ since the delimiter / now occurs within the text. However, ?x:= x/2? would be suitable. Note that /GOTO/ and /GO TO/ are different character strings, i.e. spaces are significant. University of Leeds 9/1/75 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 32 - 0 5.5.2 Endpoint Many editing instructions specify that a particular operation is to be carried out up to a certain place in the old file. This place is known as the endpoint and can be specified in several ways. The general format of an endpoint specification is <record>.<character> <record> specifies the record of the oldfile which is to be the endpoint. It may be omitted in which case the current record is assumed but the . must be present. .<character> specifies the character position of the endpoint within the record. It may be omitted in which case the start of the specified record is assumed. In what follows n signifies an integer and string signifies a character string as defined in section 5.5.1. The following forms may be used and have the effect stated. Specifying a record #n record number n of the oldfile, the first record being record 0. n n records from the beginning of the current record. string The next record beginning with the specified string of characters. Note that spaces are significant. S string The next record which Starts with the string specified, ignoring leading spaces. C string The next record which Contains the specified character string. E The End of the file, i.e. the record which is an imaginary record after the last actual record. Specifying a character position .#n Character number n in the current record, the first character being 0. .n If used with a record specification then n characters from the start of the record. If the record specification is omitted or is zero then n characters from the current position. .string The first character of the next occurrence of the string within the current record. .E The End of the record. .S The next non-space character. University of Leeds 6/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 33 - 0 5.5.3 Transcription and deletion of records and characters T<endpoint> transcribes (or copies) characters from the old file to the new file starting at the current position and continuing to the endpoint specified. P<endpoint> positions the pointer at the endpoint specified. No text is copied over from the old to the new file so that this in effect deletes text. Note that with this instruction only the pointer may be moved backwards by specifying the endpoint in the form -n or #n only. This facility enables the contents of a file to be re-ordered. E transcribes the rest of the old file to the new file and terminates the edit (see section 5.5.8). Consider the file THE QUICK BBROWN FOX JUMPED OVER THE LAZY LAZY DOG The pointer is initially at 0.0 T.10 would copy THE QUICK to the new file leaving the pointer before the first B of BBROWN, P.1 would move the pointer past the first B of BBROWN (effectively omitting this B), T1./LAZY/ would copy the rest of the first record (record 0) and all of the 2nd record up to LAZY, P.E would move the pointer to the end of the 2nd record, effectively erasing LAZY, and E would copy the rest of the oldfile and terminate the edit. Thus, the sequence T.10,P.1,T1./LAZY/,P.E,E would produce the file THE QUICK BROWN FOX JUMPED OVER THE LAZY DOG Note the separation of editing instructions by commas. There are clearly a large number of ways of achieving the same effect, e.g. T./BB/,P.1,T1.16,P.4,E is equivalent to the sequence above. Note that if a transcribe (T) instruction moves the pointer University of Leeds 13/12/74 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 34 - 0 past the end of a record then that record is extended as necessary in the new file by the addition of spaces. If a position (P) instruction moves from the start of a record to the start of another record then intervening records are deleted. If a P instruction starts from within a record then the front of the starting record is joined to the endpoint record. For example, if the sequence T1.25,P1,E were applied to the file considered earlier the result would be THE QUICK BBROWN FOX JUMPED OVER THE LAZY LAZY DOG 5.5.4 Inserting text 5.5.4.1 The Insert instruction The I instruction is used to insert information into the new file. The string must be delimited by a pair of identical delimiters from the set previously given and has the format I<character string>. Unlike any other instruction, the string may occupy more than one record. If a multi-record insert is being made on-line, the user types an Accept where he requires a new record in the string. The system will then remind him that the second delimiter has not been given by replying with the delimiter and the invitation to type, e.g. /_ instead of _ where / is the string delimiter being used. Consider the file ABCDEF GHI The pointer is initially at 0.0 T./D/ would transcribe to before the D, I? ? would insert a new-line, T/G/ would transcribe to the record beginning with a G, I?XYZ ? would insert a record of XYZ, TE would copy the rest of the old file, I?**** would insert a new record of **** at the end of ? the new file. University of Leeds 6/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 35 - 0 The result would be ABC DEF XYZ GHI **** If the second Insert had been I/XYZ/ the result would instead have been ABC DEF XYZGHI **** because a new record was not started. Note that when inserting a number of short records it can be inconvenient to input several lines (particularly on-line, where following an Accept the user must await a response). A double delimiter will be taken as a newline, for example I?ABC??DEF??? is equivalent to I?ABC DEF ? 5.5.4.2 The Replace Instruction The Replace (R) instruction has the format: R/oldtext/newtext/ and causes the next occurrence of oldtext in the current record to be replaced by newtext, where / may be any of the allowed string delimiters. For example, if the current record is JAN FEB MARCH APR and the pointer is at the beginning of the sequence, then R/CH// would change the record to: JAN FEB MAR APR Note that to retain the position of APR, the instruction would be R/CH/ /. R/CH// is equivalent to T./CH/,P.2 and R/CH/ / is equivalent to T./CH/,P.2,I/ /. University of Leeds 12/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 36 - 0 5.5.4.3 The After and Before instruction The A and B instructions have the format: A/oldtext/newtext/ and B/oldtext/newtext/ where / may be any of the allowed string delimiters. They cause the current record to be transcribed to after or before the first occurrence of the oldtext specified, and then the newtext to be inserted. Thus, if the pointer is at the first character of SUNDAYTUESDAY then either B/T/MONDAY/ or A/Y/MONDAY/ would convert the record to SUNDAYMONDAYTUESDAY Note that A/oldstring/newstring/ is equivalent to T./oldstring/,T.n,I/newstring/ where n is the number of characters in oldstring. Also, B/oldstring/newstring/ is equivalent to T./oldstring/,I/newstring/. 5.5.5 Repetition B,M A sequence of editing instructions may be repeated by placing the sequence in brackets, and following it either with *n or <endpoint>. *n means that the sequence should be repeated n times. <endpoint> means that repetition should be performed until the pointer reaches <endpoint>. For example, to change all statements of the form FORMAT(xxx,xxx) in a Fortran program to FORMAT(1H ,xxx,xxx) the required instructions would be (TC/FORMAT/,R/(/(1H ,/)E,E This says "transcribe to any line containing FORMAT, replace the first occurrence of a left hand bracket with (1H , then repeat this sequence until the end of the file, then terminate the edit". Note that the use of the TC string facility in this way is somewhat expensive in processor utilisation. University of Leeds 13/12/74 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 37 - 0 5.5.6 Merging files The editor in FAAST and Eldon3 (F,E) allows only the merging of a single file into the file being edited. Full details are included in Section 6. The George editor (B,M) allows a number of files to be edited and merged into a single new file during one edit by using the Merge (M) instruction which has the format: M<filename> This causes the current old file to be closed and the position of the pointer in that file to be remembered. The file specified in the M instruction is then opened with the pointer at 0.0, and may then be edited. A file that is closed as a result of the M instruction is placed at the top of a push-down stack. Subsequent M instructions place files on the top of the stack, and cause the pointer position to be remembered. Up to ten old files may be in use at any one time. The X instruction, which has the format: X causes the current old-file to be closed, and for the top file in the stack to be reopened as the current old file, with the pointer in the same position as when it was put on the stack. Suppose ALPHA contains FIRST THIRD BETA contains SECOND If the pointer is at 0.0 of ALPHA, then T1,MBETA,TE,X,TE would create a new file of FIRST SECOND THIRD Note that a file may be merged with itself. This can be especially useful for re-ordering a file. Thus, if FRED contains ABC GHI DEF The instructions CORRECT FRED T1,P1,TE,M FRED(-1),P1,T1,X,E would create a new file ABC DEF GHI { University of Leeds 9/1/75 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 38 - 0 Note the use of FRED(-1) in this M instruction. This is necessary since the CORRECT command creates a new file called FRED and the old file is therefore now FRED(-1). Notice also that the same effect could be achieved by CORRECT FRED T1,P1,T1,P-2,T1,PE,E where P-2 specifies a backwards positioning of the pointer. 5.5.7 The S instruction F,E only This instruction is used to represent on cards or GRAPHIC paper tape editing instructions for NORMAL files. Thus the requirement is to be able to represent both upper case (big) letters and lower case (small) letters. The S instruction takes the form: S <char> where <char> is any character. S should be used once before any other editing instructions. <char> will then have a special meaning when used in strings; <char> will no longer be regarded as part of the string in which it appears but will be interpreted to mean case inversion. Essentially the effect is that all letters are assumed to be in lower case unless they are enclosed in occurrences of the special character <char>. For example, if S' is used then the string 'REAL' X,Y; will be interpreted as REAL x,y; The exact effect of S is as follows. Whenever a string is used in an editing instruction any letters in the string are assumed to be in lower case until the first occurrence of the special case inversion character ', for example. After ' letters are assumed to be in upper case until the next occurrence of ' when the case reverts to lower, and so on. In illustration, suppose an Algol68 program in a NORMAL file contains the following line: IF x = 0 THEN GOTO rubbish FI; Having used S' , the instruction to transcribe to this line is T/'IF' X = 0/ In order to replace rubbish FI; by nonsense ELSE the required instruction is R/RUBBISH 'FI';/NONSENSE 'ELSE'/ University of Leeds 8/1/75 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 39 - 0 5.5.8 Other facilities A number of other facilities are available within the editor. For a full description of these Chapter 6 of the George reference manual should be consulted. 5.5.9 Terminating or abandoning the edit Normally an edit is terminated by the E instruction which has already been described in section 5.5.3. The rest of the oldfile is automatically copied to the new file before control is returned to the George command source. If the editor was entered via the CORRECT macro then the oldfile is erased and only the new file retained. When using the editor on-line it is possible to abandon an edit by means of the Q (Quit) instruction. The edit is terminated immediately and if the editor was entered via the CORRECT macro the incomplete new file is erased and only the old file is retained: If the edit was entered by the EDIT command then the new file is left as it was before the edit. 5.6 Special features for editing on-line Any fault in the editing instructions produces a suitable error message. (The most common messages are listed in section 5.7). If editing off-line the message is simply sent to the monitoring file of the job and the edit continues. If editing on-line the message is sent to the terminal and control is returned to the console. The user can then decide what to do according to the circumstances. A number of features of the editor are designed specifically to simplify on-line editing. 5.6.1 The Window facility The user can switch on a "window" facility. If the switch is on and the pointer is moved to a new record by a T or P instruction then that record is listed on the console. The window facility is controlled by the following instructions: W ON switches the window on, W OFF switches the window off, W reverses the state of the switch. 5.6.2 The Listing facility This is controlled by the instructions L ON, L OFF and L in the same way as the window facility. If listing is switched on then all lines transcribed to the new file are listed on the console. This facility should be used with caution. Having made some alterations to a line a useful sequence to see whether the line is now correct is L,1,L This is on the assumption that listing is initially switched off. University of Leeds 9/1/75 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 40 - 0 5.6.3 The F (Forget) instruction The F instruction has the effect of resetting the pointer to the position it was at before the last editing record was obeyed. Any records copied to the new file as a result of instructions in the last editing record are removed. E.g. P26 F,T1 is equivalent to T1. This instruction is a useful dodge when a mistake has been made, but note that two or more consecutive F instructions are not allowed. 5.6.4 Break-in during an edit If the Control A key is pressed while the editor is obeying an instruction then the following message is output: INSTRUCTION TERMINATED and new editing instructions may then be typed in as desired. 5.7 Editor messages The most common editor messages are: a) CHARACTER NOT FOUND T, A, B or R instruction specifies a non-existent position in the current record. b) INSTRUCTION TERMINATED Broken-in while the instruction was being executed. c) SYNTAX ERROR: incorrect Invalid instruction. instruction d) YOU'VE RUN OFF THE END Trying to move pointer past OF THE FILE the end of the file. University of Leeds 9/11/78 Amendment E5 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 41 - 0 6. Subsystems FAAST and Eldon3 are two subsystems running under George. The reasons for having these subsystems were explained in section 2. In this section the facilities available in these subsystems are presented. In particular we introduce some new ways of running programs which are particularly suitable for developing programs and introduce two additional commands FAASTPROG and RUN. The following diagram which summarises all ways of running of programs may help in understanding the material that follows. 0---------------------------0 ! diagram of ways of ! ! RUNNING PROGRAMS VIA THE ! ! JOBWELL AND THE FAASTWELL ! 0---------------------------0 University of Leeds 12/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 42 - 0 6.1 Fortran, Algol and Algol68 Short Turnround system (FAAST) Most Fortran, Algol60, Algol68 and Snobol programs can be run under FAAST and most of the George commands described in this Section can be used. The compilers in FAAST are: Fortran - FLAIR, provided by ICL. Algol60 - MALG, written at Manchester University. Algol68 - the RRE compiler (see Section Q). Spitbol - The Leeds 1900 Snobol compiler. In addition to providing a better turnround the MALG and FLAIR compilers provide vastly improved diagnostics for debugging programs. Full details of these compilers are included in the relevant language Sections F, G, Q and P. Additionally, it may be convenient to use the editor alone in FAAST since it provides facilities (the S instruction) for editing NORMAL files which are not otherwise available (see section 5.5.7). Jobs which conform to the following rules can be run under FAAST: 6.1.1 Jobs and commands Jobs for FAAST may be submitted on cards or GRAPHIC paper tape. The JOB command is as described previously. The following commands may be used within a job: PROG CORRECT EDIT (ED) LISTFILE (LF) LISTDIR (LD) ERASE (ER) ENDJOB (EJ) An attempt to use any other command will produce a warning message and such commands will then be ignored. Only one PROG command may appear in a job and it must be the last command in the job. If an attempt to use a file which is not on-line is made an error message will be output and retrieval of the file initiated. The job must in this event be resubmitted. There is a macro command FAASTPROG which is analogous in action to the RUNJOB command. RUNJOB initiates an off-line job to run under George; FAASTPROG allows a user at an on-line console to initiate a job to run under FAAST. There follows details of FAAST commands. It is assumed that the reader has read the description of the George commands with the same names. University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 43 - 0 PROG command The following parameters may be used: FORTRAN <optionally, name of a GRAPHIC file> ALGOL <optionally, name of a GRAPHIC file> ALG68 <optionally, name of a GRAPHIC or NORMAL file> SPITBOL <optionally, name of a GRAPHIC file> DATA <optionally, name of a GRAPHIC file> TL <integer less than or equal to 30>. The following parameters may be used with ALG68 only: NOLIST This suppresses the program listing LIB <album name> This allows use of an album. <album name> must be an absolute name, i.e. contain a username. NORUN The program is compiled but is not run. CORRECT command The following editing instructions may be used: T P R L E S TS PS I LON TC PC A LOFF TE PE B W WON WOFF Backwards movement of the pointer is not allowed. Repetitive editing is allowed. EDIT command All the editing instructions listed under CORRECT may be used. The following (rarely required) form of the EDIT command is not available: EDIT oldfile,newfile,editfile LISTFILE (LF), LISTDIR (LD) and ERASE (ER) commands These commands are available as described previously. ENDJOB (EJ) command The RETAIN option is not available. 6.1.2 Limits on program runs 30 seconds run time 750 lines of lineprinter output. University of Leeds 8/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 44 - 0 6.1.3 Library facilities A selection of the most commonly used routines in the NAG library may be used via FAAST. A special method of library incorporation is used (see Section J). According to the language used various other library routines are available as follows: Other library routines - FLAIR The following routines are available: the normal Fortran standard functions and FERROR, TRACEOUT, DATE, FMOVE, IDATE, ITIME and TIME See also Section G. Other library routines - MALG The following routines are available without declaration: the normal Algol60 standard functions and read, readboolean. print, output, writeboolean, write, format, space, newline, paperthrow, runout, writetext, copytext, readch, nextch, skipch, code, printch, selectinput, selectoutput, freeinput and freeoutput. See also Section F. Albums - Algol68 All the facilities of the MASTERALBUM are available, that is segments: extraops, complpower, stringplus, gpseg, cputime, matrixpack and NAG routines. The user's own private albums may also be used. University of Leeds 8/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 45 - 0 Submitting jobs to FAAST from an on-line console The command FAASTPROG is available on an on-line console for submitting a job into a well of jobs to be run by FAAST. The output from the job may be routed either to a lineprinter or a file. Details of the command FAASTPROG The user must be logged in. The user types FAASTPROG <parameters> where <parameters> are any of the parameters applicable to a PROG command in FAAST (see section 6.1.1). For example: FAASTPROG ALG68 JIMSUMS,DATA JIMSDATA The effect is to submit a job to FAAST containing a PROG command as follows: PROG ALG68 JIMSUMS,DATA JIMSDATA Routing of output In the absence of a ROUTE parameter, output is printed on a central lineprinter and hence is returned to a slot in the data preparation area. If the user requires his output to be sent to a remote lineprinter or to a file he must use a ROUTE parameter to FAASTPROG. The possibilities for this are: ROUTE CENTRAL UPSTAIRS ENG BRAD SHEFF HULL YORK S-X output sent to file S-XFAAST-OP <filename> output sent to file <filename> When a job which was submitted by FAASTPROG and which sent its output to a file terminates, a broadcast is sent to the user. This is of the form: FAAST RESULTS IN FILE <filename> The user will receive the broadcast message on his teletype only if he is still logged in with the same jobname as when issuing the FAASTPROG command. University of Leeds 12/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 46 - 0 6.2 The Eldon3 terminal system This section summarises the major differences between Eldon3 terminal facilities and MOP facilities. Attention is particularly drawn to the RUN facility, available on Eldon3, which provides a very convenient way of developing fairly simple programs. 6.2.1 Running programs The commands available for running programs are: RUN This command allows compilation and execution of an Algol60, Fortran or Algol68 program with output returned to the console. The time between issuing RUN and receiving output is normally a few minutes. The compilers used are Malg, Flair and Algol68-R (See section 6.1 above and Sections F, G and Q). The following parameters may be used: ALGOL <name of a GRAPHIC file holding program> ALG68 <name of a GRAPHIC or NORMAL file holding program> FORTRAN <name of a GRAPHIC file holding program> DATA <name of a GRAPHIC file containing data> The following parameters, relevant only to an Algol68 program, may also be used: TL <number> if <number> is 0 the program is compiled but not run. LIB <albumname> to be used if an album is required. <albumname> must be an absolute name, i.e. contain a username. An efficient, and perhaps more convenient, way of presenting data, as an alternative to the DATA parameter, is to include the data in the file holding the program and separated from it by a line ***D for Algol, or *DATA for Fortran and Algol68 E.g. 'BEGIN' PRINT(READ,10,5) 'END' ***D 23.421 Similarly, MASTER TEST : FINISH *DATA 12.3 7.2 University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 46 - 1 After this command is typed the system replies RUN ACCEPTED if the parameters are acceptable. The terminal goes "dead" while the user waits in a queue. When the user's turn comes round the system types RUN STARTING and when the run is complete the output is automatically printed on the terminal. While waiting for the message RUN STARTING the user may break-in as usual. However, once the program is running (i.e. after the message RUN STARTING) break-in is ignored. Limits on the run 10 seconds run time, 750 lines of output. FAASTPROG This command inserts an entry into the queue of programs to be run by FAAST. Full details are given in section 6.1.4 under FAAST. RUNJOB Standard, but the user must be logged in. 6.2.2 File Manipulation The commands available are: INPUT standard (i.e. same as MOP) ERASE standard TRAPGO standard LISTFILE standard CORRECT and EDIT The following editing instructions may be used: T P R L E S M Q TS PS I LON X F TC PC A LOFF TE PE B W WON WOFF files, section 6.2.3). Repetitive editing is available. It is necessary for some Eldon 3 commands that files to be used should be trapped to :MANAGER. Consequently the Eldon 3 TRAPGO command gives traps to :MANAGER in addition to any which are specified. The commands EDIT, CORRECT, RUN and LISTFILE will accept as the name of an input file !! This means "the file last accessed by one of these commands". The facility is designed to reduce repeated typing of the same name. e.g. CORRECT !! RUN ALGOL !! University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 46 - 2 6.2.3 Merging Files For reasons of efficiency merging files in Eldon 3 is different from MOP/George. The file from which you are merging must be specified in a parameter supplied with the CORRECT or EDIT command. For instance if you are correcting a file FRED and wish to merge from a file BLOGGS you should type CORRECT FRED,<-BLOGGS Note that <- is two characters < and - and not a backward pointing arrow. Similarly EDIT FRED,JOE,<-BLOGGS At the point in the sequencing of editing instructions where you require to use the merge file, you should type M (without filename) and to return from the merge file type X as normal. It should be clear that only one merge file can be used in an EDIT or CORRECT. 6.2.4 LISTDIR command The first parameter is optional and specifies the directory required. If blank, the current directory is assumed. If the listing is to a teletype the second parameter should be left blank because listing level LOW only is available. If the listing is to a lineprinter HIGH may be specified. The third parameter may be blank or *LP. The fourth parameter should be blank unless the listing is to a lineprinter in which case it may be PROPERTY property name. The fifth parameter may be a string of characters (up to 12). This allows selective listing since only the entries starting with this string are listed, e.g. LD ,,,,STP University of Leeds 8/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 47 - 0 APPENDIX 1: Username prefixes - departmental codes Department Name Prefix Department Name Prefix Astbury Dept.of Biophysics BP1 Medical School Depts. MED (except those separately Biochemistry BC stated on this sheet) Bradford University BRA Medical Physics MPH Ceramics CER Metallurgy MET Chemical Engineering CHE Mining & Mineral Science MIN Chemical Pathology PAT Operational Research Unit OR1 Civil Engineering CE1 Paediatrics MED CE2 Pharmacology MED Commercial Users COM Phonetics PHN Community Medicine CME Physical Chemistry PHC Computer Studies CSC Physical Education PED Computing Service ECL Physics ( PH1 Cookridge Radiation Unit MED ( PH2 Dentistry DEN Plant Sciences PLS Earth Sciences EAR Proctor Dept.of Food PRC & Leather Science Education INS Psychiatry PSY Electrical & Electronic ( EE1 Engineering ( EE2 Registry REG English ENG Sheffield University SHE Fuel & Combustion Science FUE Social Sciences: Sociology SOC Geography GEO Psychology PSC Management Sciences) Genetics MED Economics ) SSC Social Studies ) History HIS Sundry Users SUN Hull University HUL Television Service TV1 Inorganic & Structural INC Chemistry Textile Industries TEX Linguistics LIN Transport Studies TRA Mathematics MAT York University YOR Mechanical Engineering ( ME1 Zoology ZOO ( ME2 ( ME3 University of Leeds 8/11/78 Amendment E5 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 48 - 0 APPENDIX 2: Macros available Details of all general purpose macros are collected together in this appendix. The specifications of macros for running specific packages are given in Section K. 1. Summary of general macros in use at Leeds Macro Number Description PROG *M1 This is the accepted macro for compiling and running almost all programs at Leeds. CORRECT *M2 Provides a straightforward means of editing files. NEWS M3 In response to the NEWS macro command a listing of the latest software news is produced. The most recent items are earliest in the listing. PICTURE *M4 This is designed to process a graphics file onto any output device capable of accepting graphical output (e.g. lineprinter, teletype, Tektronix VDU, incremental plotter). A full specification is given in Section M. CHANGE M15 Converts Fortran card images in a file from either IBM O26 or O29 code to ICL 1900 code. LISTLDSA *M16 Provides a listing of the source text of a specified library routine whose semi-compiled is in SUBGROUPLDSA, see Section J. LISTMT *M17 Provides a diagnostic listing of the contents of a "magnetic tape", see Section L. FILELIST *M18 Converts a NORMAL file to a GRAPHIC file in which letters in upper case are placed within quotes. This facility is particularly useful with Algol 68 programs. The graphic file produced is listed and may optionally be retained, see Section Q. * denotes that a full specification of the macro is given in this manual. Macros of wide applicability will be found in section 2 (below); more specialised macros in other Sections as indicated. Specifications of macros without an asterisk are available in the Programming Advisory Service. University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 49 - 0 SOAP *M19 "Simplify Obscure Algol Programs". A program to organise the layout of an Algol60 program to aid comprehension. NULLIB *M20 Enables users to create and update their own libraries. Full details are included in Section J. NULLIST *M21 Produces a listing of the routines contained in either a XFYZ-type library file (i.e. one created by using either #XFYZ or NULLIB) or in a file of semi-compiled. Full details are included in Section J. 2. Full specification of general macros University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 50 - 0 M1 The PROG macro 8/1/75 Purpose PROG is a general purpose macro designed to enable users to run their programs without having to use George job command language (JCL). With this macro, a user programming in any of the languages in use at Leeds can compile and run his program, produce a binary program or run a binary program with all the peripherals necessary. Use To use the macro, the user should type PROG, followed by a space, followed by a list of parameters, each separated from the next by a comma, and in any order. The maximum number of such parameters to be used in any one call of PROG is eighteen. Action The macro uses its parameter list to produce suitable JCL for running a user's job. If only one printer channel is used it will be automatically printed. Additionally, on-line, up to the first 100 lines of output from the last phase entered will be printed on the terminal. Where more than one printer channel is used only output for the first channel specified in the PROG parameter list will be printed; other printer files will not be printed. Off-line, the last JCL statement obeyed will normally be ENDJOB; where required this ENDJOB can be avoided. On-line, control is returned to the command source (the on-line console). Examples of PROG calls and their effect PROG FORTRAN a) Compiles, consolidates and runs a Fortran program whose source lines follow this call. b) Reads in any data following the source text on either CR0 or TR0. c) Provides a default maximum runtime of 60 secs. PROG ALGOL FX,DATA FXDATA,PMD a) Compiles, consolidates and runs an Algol program held in the file FX. b) Reads in its data from file FXDATA. c) At an execution error produces a Post Mortem Dump, providing the program has a 'PMD' program description statement. d) Provides a default maximum runtime of 60 secs. PROG ALGOL FX,LIB SUBGROUPNAGA,TL 15,PT a) Compiles, consolidates and runs an Algol program held in the graphic file FX, generated from paper tape. b) Incorporates routines from :LIB.SUBGROUPNAGA into the program provided the program has a 'LIBRARY' program description statement. c) Provides a maximum runtime of 15 secs. d) Reads in any data following this call. University of Leeds 13/1/75 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 51 - 0 PROG FORTRAN FY,LIB SUBGROUPNAGF,SAVE FYBIN,NORUN,EXIT a) Compiles and consolidates a Fortran program held in file FY but does not run it. b) Incorporates routines from :LIB.SUBGROUPNAGF into the program provided the program has a LIBRARY compiling system statement. c) Saves the binary in a file called FYBIN. d) Allows the user to obey further JCL as no EJ is obeyed. PROG BIN FYBIN,TL 80,FILE*MT0=MTFILE(READ),*CR0 a) Runs the binary program FYBIN. b) Provides a maximum runtime of 80 secs. c) Reads in data from the magnetic tape file MYFILE. d) Reads in data following this call (on cards). e) Outputs to the default line printer LP0. PROG ALGOL FX,SAVE FXBIN,PMD FXPMD,DATA FXDATA a) Compiles, consolidates and runs an Algol program held in the file FX. b) Saves the binary in a file called FXBIN. c) Uses FXPMD as its Post Mortem Dump file, for further use when running FXBIN, provided the program has a 'PMD' program description statement. d) Reads in its data from file FXDATA. e) Provides the default maximum runtime of 60 secs. PROG BIN FXBIN,TL 100,PMD FXPMD a) Runs the binary program FXBIN. b) Reads in any data following this call. c) Provides a maximum runtime of 100 secs. d) Uses FXPMD as its Post Mortem Dump file Notation In the following description, the abbreviation PN is a generalised peripheral name, which may be any one of CP, CR, DA, FR, FW, GP, LP, MT, TP or TR. Not all of these may be applicable in any one case. Parameters may include an item described within < and >; these brackets should not be punched, see examples above. Parameters The parameters available with PROG are listed and fully described below. They may occur in any order. Where not explicitly stated otherwise, any parameter is optional and may not occur more than once. University of Leeds 13/1/75 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 52 - 0 language - ALGOL, ALG68, FORTRAN, PLAN, COBOL, SPITBOL or BCPL. LIB - inclusion of semicompiled or library material at consolidation time. BIN - running of a binary file. SAVE - saving of a binary file. NORUN - the binary program is not entered. PT - indicates GRAPHIC mode paper tape programs. PTFM - indicates NORMAL mode paper tape in Algol 60. ST - stack parameter in ALG68. TL - time limit at run time. ROUTE - for routing output to different sites. PMD - post mortem dump facility in ALGOL and ALG68. NOLIST - inhibits listing of named lineprinter output. DATA - single input/output data streams. ???????? - for multichannel or named I/0 files. * - for single or multichannel input/output. PLOT - graphical facilities. EXIT - circumvents the ENDJOB command. RT - retains the monitoring file. OUTSEMI - for saving semicompiled output. CONS - for free standing consolidation. OPT - optimising facilities in FORTRAN and ALG68. COMPF - for saving failed compilation output. language<filename> Here the name language is used as a generalised language name, which may be ALGOL, ALG68, FORTRAN, PLAN, COBOL, SPITBOL or BCPL. There will be additions to this list as new languages are adopted from time to time. Use This parameter defines the compiler to be used to compile the program. Either this or a BIN or CONS parameter is compulsory. <filename> specifies the file which contains the text of the program to be translated. On-line <filename> must be present. Off-line If <filename> is absent, the source text will be read from the job source (either cards or paper tape). Action The program text in file <filename> will be compiled, consolidated if compilation has been successful, and run provided consolidation has been successful and there is no NORUN parameter. If no peripheral parameters (DATA, FILE* or * parameters) are given then *LP0, *TR0 and *CR0 are made available. University of Leeds 9/11/78 Amendment E5 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 53 - 0 An Algol60 or Fortran program that compiled and ran successfully will produce a file which contains the compilation and consolidation listings. This file will be called S-XS-XS-XS-X where compilation is from the job source or S-X<filename> where <filename> is the first nine characters of the file containing the source text. This output will not be automatically listed and, like all S-X temporary files, will be erased if it is not accessed for two weeks. LIB<libfilename> Use This parameter is meaningful only with a language or CONS parameter. It is used at consolidation time when material from a library file and/or from a semicompiled file is required. With a language parameter, unlike a CONS parameter, no LIB parameter is required for a single search of the appropriate standard library file. Each LIB parameter should correspond to a LIBRARY, or SEMICOMPILED statement in the program description and they should occur in the order in which the libraries are to be searched and/or semicompiled files are to be incorporated. Up to 11 such parameters may occur in a call of PROG. Unless specified otherwise <libfilename> is assumed to belong to the user :LIB. This will be true for all standard libraries but not for the user's own (private) libraries or files of semicompiled. BIN<binfilename> Use This parameter will be used to run a previously SAVEd binary program. <binfilename> must be present. Action The BINary program stored in the file <binfilename> will be loaded, suitable default peripheral channels (*LP0, *CR0 and *TR0) will be assigned if none are specified, and the program entered. SAVE<binfilename> Use This parameter causes the binary program produced after successful compilation and consolidation to be saved in a file <binfilename>. NORUN Use This parameter inhibits the running of a binary program which has just been produced by compilation and/or consolidation. It is generally used in conjunction with the SAVE parameter. University of Leeds 9/11/78 Amendment E5 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 54 - 0 PT Use This parameter should be used with GRAPHIC paper tape programs. PTFM Use This parameter is meaningful only with Algol 60 programs. It must be specified with NORMAL paper tape programs, i.e. programs containing lower case letters, abc...xyz, tab characters etc. When used, a MODE(NORMAL) parameter will be needed for the JOB command that introduces the job if the program text follows the call of the PROG macro. Action In the case of load-and-go running, there must be a blank line between the end of the program and the beginning of the data. ST<stacksize> Use This parameter may be used with ALG68 to increase the stack size. TL<timelimit> Use This parameter indicates the maximum time, in seconds, for which the program is to run. It is only applicable to off-line jobs since all on-line jobs are given a time limit of 15 seconds. If the parameter is absent a time of 60 seconds will be given by default. Action The run will be terminated if it attempts to exceed the specified or default timelimit. ROUTE<property> Use This parameter may be used to direct all the output generated by a PROG call to a line printer with the specified property. <property> is one of the following: CENTRAL, ENG, LINES, NOLINES, UPSTAIRS, YORK, HULL, BRAD or SHEFF. Only one option may be used. University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 55 - 0 PMD<pmdfilename> Use This parameter is meaningful only with ALGOL, ALG68 or when running the binary of an Algol program. In Algol should be used only in conjunction with a 'PMD' program description statement. Action If <pmdfilename> is omitted a workfile will be claimed and used for that run of the program only. Where a run of a binary file is required <pmdfilename> cannot be omitted and the same PMD<pmdfilename> should be used with both the PROG ALGOL/ALG68, when creating the binary and the PROG BIN when running the program. <pmdfilename> is a direct access file which need not exist. NOLIST Use This parameter may be used to suppress the (default) listing of a FILE*LPn file. DATA<datafilename> Use This parameter will be used with a program requiring only a single stream of input data at run-time. It cannot be used with a FILE* or * parameter. On-line <datafilename> must be present. Off-line If <datafilename> is absent or the whole parameter is missing, then data will be read from the job source. Action If this parameter is present, *CR0 and *TR0 are assigned to the appropriate source of data (except for a COBOL program where *CR1 and *TR1 are used) and *LP0 to the output channel. University of Leeds 15/1/75 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 56 - 0 FILE*PNnn=<filename> Use This parameter should be used only if channels other than the default ones are required or if named files are needed on output channels. A FILE* parameter cannot be used in conjunction with a DATA parameter and <filename> should not be omitted. <filename> may be followed by such qualifiers as are required by use. Action The file <filename> (which may be qualified) will be assigned to the peripheral PN on unit number nn. Thus, FILE*LP0 = OUTPUTFILE(WRITE) would write output for *LP0 to file OUTPUTFILE. Similary, FILE*MT1 = MAGFILE(EMPTY) would cause output for *MT1 to be written to the file MAGFILE, creating the file if it does not exist. Note If any channel is defined by means of a FILE* or * parameter, then all channels used must be defined except when LP0 is the only output channel in which case it need not be defined. Thus the FILE* parameter may occur more than once. ! files should not be used with this parameter. University of Leeds 15/1/75 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 57 - 0 *PNnn=<peripheraldescription> Use This parameter is used to connect a real peripheral such as a magnetic tape or an exotic peripheral to a core image. This parameter cannot be used in conjunction with a DATA parameter and <peripheraldescription> should not be omitted except when connecting slow peripherals to the job source. <peripheraldescription> may be followed by such qualifiers as are required by use. Action The required peripheral (which may be qualified) will be onlined to peripheral PN on unit number nn. Thus, *MT1=(10117) will online the magnetic tape with serial number 10117 to *MT1. Similarly, *TR0=BINIMAGEPT will online *TR0 to read a document headed DOCUMENT BINIMAGEPT for the program. Note If any channel is defined by means of a FILE* or * parameter, then all channels used must be defined except when LP0 is the only output channel in which case it need not be defined. Thus the * parameter may occur more than once. When using this parameter to online real magnetic tapes, it is recommended that the facility is only used off-line where previous warning of magnetic tape usage may be given to the operators. ! files should not be used with this parameter. University of Leeds 9/1/75 Amendment E3 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 58 - 0 PLOT<plotfilename> Use This parameter should be present when running a program using the Leeds graph plotter routines. Action The graph plotter macro instructions will be written to a file <plotfilename>, where they may subsequently be used to produce graphical output using the PICTURE macro (See Section M). An enhanced form of this parameter is available which allows the PICTURE macro to be automatically called from within the PROG macro. This is done by enclosing the parameters that would be given to the PICTURE macro in brackets following PLOT. If no filename is given then a temporary named file is used [of the format G<11 characters>(/PLOT)]. Thus, a) PROG ALGOL ATEST,LIB SUBGROUPLDSA,PLOT(*LP) will send plotting output to the lineprinter, b) PROG BIN MYFILE,PLOT(GRAF,*GP),DATA will produce a plotfile GRAF and plot this on the graph plotter. If the PROG command does not terminate successfully the PICTURE macro is not called, and if no filename is given to PLOT the temporary plotting file is erased. EXIT<label> Use This parameter enables the user to by-pass the ENDJOB command (in PROG) and continue obeying his job description from <label>, e.g. to list or erase a file, change access traps, etc. Action <label> should be a label beginning with a digit and have Z for its second letter, e.g. 2ZEX. Thus, EXIT 1ZLAB will transfer control to the label 1ZLAB in the user's job description. <label> need not occur, in which case control is transferred to the next command in the job. Nevertheless, where data follows the call of PROG <label> should be specified to prevent any attempt to interpret unused data after a failure as commands. Users writing their own job descriptions are reminded of the necessity of an ENDJOB command. University of Leeds 8/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 59 - 0 RT<filename> Use This parameter may be used to retain the monitor file, for later listing - if required. Note that the listing of this file will require a SPECIAL parameter with the LF command. OUTSEMI<semifilename> Use This parameter allows PROG to be used for mixed language programming. It enables a user to output semicompiled to a file <semifilename>, which can later be consolidated. <semifilename> is a direct access file which need not exist. For BCPL users this parameter is compulsory and must correspond in name to the parameter in the steering line. CONS<filename> Use This parameter enables free-standing consolidation of a set of semi-compiled and library files. The necessary consolidator steering lines (Section N) follow the call of PROG if <filename> is omitted, otherwise they are in <filename>. OPT Use This parameter is only relevant to FORTRAN and ALG68 compilations. In FORTRAN it causes the optimising Fortran compiler to be used instead of the standard version. It should be used only with working tested programs which satisfy the restrictions placed on Fortran for optimization. In ALG68 it may be used: OPT7 or OPT inhibits overflow and array bound checking, OPT3 inhibits array bound checking, OPT4 inhibits overflow checking. COMPF<filename> Use This parameter may be used to direct the output from an unsuccessful compilation to the file <filename>. University of Leeds 8/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 60 - 0 M2 The CORRECT macro 11/10/76 Purpose To enable the user to edit his files with the minimum of inconvenience. Advantages compared with EDIT include: a) Old files are always ERASEd after a successful edit, and thus the backing store is kept free of unwanted files. b) Use of either or both of the RERUN or EXIT parameters gives greater control of the JOB under restart or error conditions. Action a) On-line A new file is produced and retained, and the old file is ERased unless the reply EDIT ABANDONED appears. b) Off-line The old-file is ERased only if no errors are reported. Parameters filename The name of the file to be edited must be given as the first parameter. <filename> must not include a generation number or language code. TS(access modes) Use If used this parameter must be the second parameter. The new file will be created with the specified access modes closed. The possible modes are EXECUTE, READ, APPEND, WRITE and ERASE. RERUN If this parameter is present then if the job containing the CORRECT is restarted the edit will be carried out. If the parameter is absent then when a job is restarted the CORRECT will not be done. EXIT <label> Use This parameter may be used to terminate or direct an off-line job if the edit is unsuccessful. If no label is given the job will be terminated, otherwise control will be transferred to the label. University of Leeds 11/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 61 - 0 M19 The SOAP macro 12/10/76 Purpose This macro runs the SOAP program originated at NPL. SOAP is an acronym for Simplification of Obscure Algol Programs. Soap reorganises the layout of an Algol program to a standard suitable for technical papers, theses etc. An organised layout aids understanding and also helps in identifying errors in a program. Use The macro operates on a GRAPHIC file (or a NORMAL file if specified) and produces a file of generation number one greater than the old one and lists it. This action is obtained by SOAP filename where filename is the filename without the generation number, the latest generation number always being used by the macro. Additional optional parameters, which may appear in any order after filename, and separated by commas are: NOLIST No listing is produced, EROLD Erases the old file, ERNEW Erases the new file, NORMAL Essential for NORMAL files, TABS n Sets the indentation for each new paragraph in the SOAPed file to n spaces. The default value is 4 spaces. LINELIMIT n Sets the maximum number of characters per line in the SOAPed file to n characters. The default is 72 characters per line, or 100 characters per line if the NORMAL parameter is also present. NOLINES If this parameter is present then the listing will be produced centrally on un-lined paper. By default, the listing is produced on lined paper at the cluster from which the job was submitted. EXIT Skips the ENDJOB command in SOAP. Action In the event of a failure, a listing is produced up to the point of failure, the new file is erased and the old file retained. University of Leeds 12/10/76 Amendment E4 1906A Users Manual -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - E - 27 - 0 JOB EXAMPLE,:USER,JD(JT 15,UR D) LD,,*LP TG RESULTS,WRITE #TO MAKE SURE THAT WE CAN OVERWRITE EXISTING RESULTS PROG ALGOL PRGRM1,*TR0,FILE*LP0=RESULTS(TS(WRITE,ERASE)),EXIT 1Z1 1; -2; 3; -4; 1Z1 IF DISPLAY (ERROR), EJ PROG FORTRAN PRGRM2,DATA RESULTS **** When run the following monitoring file might be produced: Line 1 DOCUMENT :USER.EXAMPLE(/B1B0) STARTED :USER,EXAMPLE, 4JAN74 13.32.05 TYPE:RJE 4 13.32.05_ JOB EXAMPLE,:USER,JD(JT 15,UR D) 13.32.05_ EXAMPLE 6 13.32.06_ LD,,*LP 7 ERROR IN LD : THIS IS NOT A COMMAND 8 13.32.08_ TG RESULTS,WRITE 9 13.32.08 #TO MAKE SURE THAT WE CAN OVERWRITE EXISTING RESULTS 10 13.32.08_ PROG ALGOL PRGRM1,*TR0,FILE*LP0=RESULTS(TS(WRITE,ERASE)),EXIT 1Z1 11 13.32.10_ TRACE FULLBUT,COMMANDS,COMERR 12 :USER.PRGRM1(3/) IS ALREADY ONLINE 13 13.33.54 0.01 USED URGENCY D 14 13.33.54 JOB IS NOW FULLY STARTED 13.33.59 0.01 SIZE GIVEN 22528 13.33.59 0.01 SIZE GIVEN 23552 17 13.34.00 FREE *CR0 ,38 TRANSFERS 18 DISPLAY : COMPILED #AAH1 13.34.01 FREE *DA1 ,9 TRANSFERS 20 0.01 Q=20K PT=25:DELETED : FI #XPCH 13.34.01 FREE *DA2 ,0 TRANSFERS 13.34.01 FREE *DA3 ,0 TRANSFERS 13.34.01 FREE *LP0 ,50 TRANSFERS 24 13.34.01 0.01 DELETED,CLOCKED 0.00 MAXQ=20K, PT=28, USED 22K 13.34.04 0.02 SIZE GIVEN 27648 SPARSE 26 13.34.05 0.02 SIZE GIVEN 36864 SPARSE 13.34.08 FREE *LP0 ,134 TRANSFERS 13.34.08 FREE *DA1 ,19 TRANSFERS 13.34.08 FREE *DA2 ,114 TRANSFERS 13.34.08 0.03 SIZE GIVEN 17408 SPARSE 31 0.03 Q=15K PT=7:HALTED : LD 13.34.08 FREE *DA15,0 TRANSFERS 33 13.34.18 FREE *TR0 ,1 TRANSFERS 34 13.34.19 FREE *LP0 ,85 TRANSFERS 35 0.04 Q=15K PT=7:HALTED : EE 36 DISPLAY: ERROR IN EXECUTION 13.34.19 FREE *DA14,0 TRANSFERS 38 13.34.19 0.05 DELETED,CLOCKED 0.01 MAXQ=15K, PT=7, USED 17K 0.05 Q=15K PT=7:DELETED 40 END OF MACRO 13.34.20_ 1Z1 IF DISPLAY (ERROR), EJ 42 13.34.21_ EJ END OF MACRO MAXIMUM ONLINE BS USED 46 KWORDS 45 13.34.21 0.05 FINISHED : 3 LISTFILES 46 BUDGET USED LEFT 47 TIME(D) 5 283 University of Leeds 12/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 28 - 0 Points to note Almost all lines specify the clock time, in the form hh.mm.ss. Messages may be produced for each command obeyed, command errors, comments, numbers of transfers performed on each peripheral channel freed, and whenever a core image is deleted, etc. - all depending on the TRACE (e.g. default) level. Note that the PROG macro suppresses commands issued and any command errors incurred. Finally note the records of time and money used and remaining. Line 1: Note the language code /B1B0 of a monitoring file. Line 3: Records the start of a job initiated from a RJE terminal. Line 4: A copy of the JOB card, including scheduling information. Lines 6-7: Omission of the obligatory space following a command generates this type of command error. Lines 8-9: A TRAPGO command has been successfully obeyed. Note that a JCL comment is copied directly into the monitoring file. Line 10: Calls of each macro obeyed are listed in full. Line 11: Modification of TRACE level by PROG. A prior FULLTRACE command could be used to override this to provide much fuller diagnostics if required. Line 12: Confirmation that the file PRGRM1 is already on-line - follows a RETRIEVE command issued by PROG. Lines 13-14:The job is charged at urgency D rate. Here the Algol compiler is loaded and entered. Lines 17-18:Confirmation that 38 card records have been read and successfully compiled. Note that in fact these records came from a GRAPHIC file. Line 20: Initiation of consolidation. XPCH is the consolidator. Line 24: Compiler deleted. Note in particular MAXQ=20K, this could be used to provide an accurate MQ scheduling parameter for a subsequent run. Line 26: SIZE GIVEN this line specifies the largest size required by the job and could be used to provide an accurate MZ scheduling parameter for a subsequent run. Line 31: HALTED: LD confirms that consolidation was successful and that the object program has been loaded. Lines 33-34:Confirmation that only 1 data record has been read, and 85 lines of printer output produced. These messages can be of much help where a failure on data input occurs, or expected output cannot be found. University of Leeds 12/10/76 Amendment E4 1906A Users Manual - -- -- -- -- -- -- -- -- - E - 28 - 1 Line 35: HALTED: EE indicates a program execution error, specified in the program output. From line 33 failure occurred before reading the second data record, i.e. 3; -4; Line 36: A DISPLAY issued by PROG - following an error. Line 38: Statement that:- a) 5 seconds processor time have been used by this job. b) 1 second processor time was used by the last core image, i.e. the object program. c) The program used up to 15K of main memory. Note that this is not MQ since compiler used 20K. d) 7 page turns occurred. e) 17 pages of the program were referenced during the program run. Line 40: End of the PROG macro. Line 41: Following the EXIT from PROG, the next JCL statement obeyed. Note that the simple form of EXIT without a label would have caused George to attempt to interpret unread data items (1 record in this case) as commands - generating a VERB FORMAT ERROR for each. Line 42: Confirmation that, following the ERROR display, ENDJOB has been obeyed, and therefore the second PROG call has not been obeyed. Line 45: Shows that the job produced 3 file listings. Lines 46-47:A self-explanatory statement of money used and allowances remaining. Note that it can be important to keep an eye on items such as: a) Elapsed time, in relation to processor time, b) Number of page turns performed, c) Amount of money used - depends on URGENCY. University of Leeds 12/10/76 Amendment E4 1906A Users Manual - - SECTION E. Revised Edition - October 1976 Instructions 1. Discard any previous edition, amendments E0-E3, in toto. 2. Insert this revised Section, less this instruction sheet. 3. Update manual status record showing that this revised Section has been incorporated. Points to note The Section has been carefully fully brought up-to-date. Many superficially minor changes have greatly changed the detail and emphasis. New sections on temporary files, the maxquota job sheduling parameter, the RENAME, TRAPLIST, ASSOCIATE, WHATSTATE and ABANDON commands, and the RESTARTED condition have been included. The documentation of the FAAST and Eldon3 subsystems has been extensively revised. Detail, though important, changes have been incorporated in the documentation of the PROG macro. Changes have been indicated by marking in the RH margin, but because of the improved emphasis and detailed changes you are strongly advised to read the revised Section in toto. University of Leeds 1/10/76 1906A Users Manual - -- -- -- -- -- -- -- -- - - END -